POV-Ray : Newsgroups : povray.general : Error with pow() : Re: Error with pow() Server Time
4 Aug 2024 14:22:56 EDT (-0400)
  Re: Error with pow()  
From: Tim Nikias v2 0
Date: 14 Jun 2003 15:13:05
Message: <3eeb73c1$1@news.povray.org>
That I understood. What I was referring to is the
int() inside the pow(). You mentioned that it might
still yield different results, that's what I was asking
about. It's funny how writing can sometimes screw
things up a little, eh? :-)

Rereading the posts with your last statement also
clears things up a little. For clarity's sake, lets just
stick to
pow( abs(X), int(Y))

I thought that it would solve most problems (like the
doc-mentioned non-integer usage for exponents), and
you replied that it wouldn't necessarily "fix" anything.
What I want to avoid is the platform-specific handling
of non-integer exponents. I assume int() would be the
way to go.
So, am I right about that?

PS: If I sound like I'm a know-better, sorry, not intended.

we're actually talking about... :-)

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

> > Hm. So I should better use floor() or ceil()? These should
> > clip to the same values for different platforms, right? And
> > why doesn't int() do that?
>
>   Hmm, you didn't seem to understand what I meant.
>
>   "1.1^30" can give and probably gives a slightly different result
> depending on the FPU used. However, the difference is in the very lowest
> digits of the result. It doesn't really matter.
>   The exact same thing happens with "1.1^30.1". The result is not
inherently
> wrong, it just isn't exact to the last digit because of the inaccuracy of
> floating point numbers.
>
>   For instance, even though mathematically "x^3*x^4" equals to "x^7",
> a typical FPU will give you a slightly different result for them for
> almost any value of x.
>   But this isn't an important error because the difference happens
> in the 15th or even higher most important digit.
>
>   Different FPUs can use different algorithms for calculating pow and
> thus give a slightly different result.
>
> -- 
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb
x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// -
Warp -


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.